What are the practical consequences of diffs in Smalltalk/C++ inheritance? A: Since Smalltalk lets you can make a subtype without making a subclass, one can be very carefree in putting data (bits, representation, data structure) into a class (ex: you might put a linked list into a Stack class). After all, if someone wants something that an array-based-Stack, they don't have to inherit from Stack; they can go off and make effectively a stand-alone class (they might even *inherit* from an Array class, even though they're not-a-kind- of-Array!).
In C++, you can't be nearly as carefree. Since only mechanism (method code), but not representation (data bits) can be overridden in subclasses, you're usually better off *not* putting the data structure in a class. This leads to the concept of Abstract Base Classes (ABCs), which are discussed in a separate question. You can change the algorithm but NOT the data structure. Bits are forever.
I like to think of the difference between an ATV and a Maseratti. An ATV [all terrain vehicle] is more fun, since you can 'play around' by driving through fields, streams, sidewalks and the like. A Maseratti, on the other hand, gets you there faster, but it forces you to stay on the road. My advice to C++ programmers is simple: stay on the road. Even if you're one of those people who like the 'expressive freedom' to drive through the bushes, don't do it in C++; it's not a good 'fit'.
Note that C++ compilers uphold the is-a semantic constraint only with 'public' inheritance. Neither containment (has-a), nor private or protected inheritance implies conformance.
